\documentclass[10pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\author{Thiago Barbosa}
\title{RESTFul WebServices}

\begin{document}
\maketitle
REST, acrônimo para Representational State Transfer é umas das tecnologias alternativas ao SOAP (Simple Object Access Protocol) e outros baseados em Web Services Description Language (WSDL).  Em 2000 foi introduzido por Roy Fielding, na Universidade da Califórnia, porém, no começo, não atraiu muita atenção. Ele se tornou integrante do Java 6 através da JSR-311. Um serviço Web REST deve seguir quatro princípios ao ser projetado.

O primeiro principio é usar métodos HTTP explicitamente. O protocolo HTTP possui métodos de requisição (request methods) que se relacionam com as operações CRUD (Create, Read, Update, Delete). Sendo assim, o request method POST deve criar um recurso no servidor (create), o request method GET deve recuperar um recurso do servidor (Read), o request method PUT deve alterar ou adicionar (Update) informações a um recurso e para excluir um recurso deve se utilizar o request method DELETE. Um dos erros mais frequentes que vemos ao se projetar um serviço é a adoção do GET para fazer operações além de recuperar um recurso do servidor. Fazer o uso do GET dessa maneira provoca efeitos colaterais. Um desses efeitos é que motores de busca podem fazer alterações não intencionais em nosso banco de dados ao executar uma requisição GET que tem o poder para fazer modificar recursos em nosso serviço. 

O segundo principio é que os serviços Web REST deve ser STATELESS. O Web Service não deve guardar o estado entre o cliente. Porém existe uma colaboração entre a aplicação cliente e o servidor.  Essa colaboração é a comunicação de requisição e resposta.

Expor a estrutura do diretório como URI (Uniform Resource Identifier) é o terceiro principio para o uso de serviços Web REST. Definir URIs de fácil compreensão com estruturas semelhantes e que possam se auto explicar pode ajudar com que o desenvolvedor tenha uma maior facilidade ao consumir um recurso. Um exemplo de URI: http://www.myservice.org/discussao/{ano}/{mes}/{dia}/{tema}. Este exemplo pode trazer todas as discussões de um fórum referente aquela data e tema. Algumas regras devem ser seguidas para a elaboração de estrutura URI para um WebService REST: Ocultar a extensão do arquivo(.jsp, .php), manter tudo em letras minúsculas, substituir os espaços com hífens ou sublinhados, evitar query string e ao invés de trazer uma pagina 404 trazer uma pagina customizada como resposta. É importante também manter a URIs estáticas, fazendo com que o link permaneça o mesmo, permitindo o bookmarking(favoritar, marcar).

O quarto e ultimo principal é permitir a transferência de arquivos xml e/ou json. O Web Service REST deve ser capaz de prover informação atual sobre o recurso solicitado (snapshot) para suas aplicações clientes, independente da plataforma ou linguagem que foi desenvolvida essa aplicação. Essas informações pode ser passadas através do corpo da resposta/requisição HTTP de acordo com o MIME TYPE, que pode ser XML ou JSON.
Usar REST nem sempre é a escolha certa. Ele for projetado para diminuir a dependência de um middleware como SOAP e outro tipos baseados em WSDL. O REST fez com que a Web retornasse a usar padrões primitivos, como URI e HTTP, e com ele também podemos encontrar uma maneira eficaz de atender os requisitos de integração entre sistemas.

\end{document}